It is established for a wireless terminal and wireless network, as part of their interoperation with each other, to perform a Radio Resource Control (RRC) Connection Establishment procedure. This is required in order to make the transition from RRC Idle mode to RRC Connected mode prior to any application data being transmitted between the terminal and the network and prior to completion of any signalling procedures.
The RRC connection establishment procedure is initiated by the terminal, which is generally referred to as a user equipment (UE) in the context of 3rd and 4th generation cellular wireless communication systems complying with European 3rd Generation Partnership Project (3GPP) standards, including Long Term Evolution (LTE).
In case of LTE, a non-access stratum (NAS) signalling message is transmitted as part of the RRC connection establishment procedure (in RRC Connection Setup Complete message), whereas in case of Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), the initial NAS message is transmitted after the RRC connection establishment procedure.
3GPP specification TS36.331, s.6.2.2 specifies that an ‘Establishment Cause’ is included in a RRC Connection Request message, the message forming a first step in the RRC connection establishment procedure.
FIG. 1 is a signalling flow diagram illustrating the signalling steps of the RRC connection establishment procedure specified in the aforesaid 3GPP specification TS36.331, s.5.3.3. Here there is illustrated a wireless terminal (UE) 102 and a network 104 represented as source and destination entities between which signals can be transmitted, the source and destination of each signal being indicated by respective vertical lines attached to, and associated with, the respective wireless terminal (UE) 102 and network 104. Signals, shown as horizontal arrows 110, 112, 114, are transmitted between the wireless terminal 102 and the network 104. In a first step, the wireless terminal (UE) 102 transmits a RRC Connection Request message 110 to the network 104. In a second step, the network 104 transmits a RRC Connection Setup message 112 to the wireless terminal (UE) 102. In a third step, and subsequent to receipt of the signal 112, the wireless terminal (UE) 102 transmits a RRC Connection Setup Complete message 114 to the network 104.
FIG. 2 is a table including a list of possible RRC Establishment Causes, noting in particular that there are two spare values for RRC cause (Spare 1, Spare 2).
FIG. 3 is a table showing, in simplified form, a relationship between the RRC cause and the (Network Access Stratum) NAS procedure as specified in TS24.301, Annex D.1. The RRC Establishment cause is determined by the NAS procedure for which the connection is being established. For example, for the NAS procedure “Attach”, there are three possible RRC Establishment Causes: Mobile Originated Signalling; Delay Tolerant Access; and Emergency.
Many Machine-Type Communication (MTC) applications executed on wireless terminals send or receive amounts of data that are much smaller than amounts of data that are sent and/or received by other types of applications, for example a voice communication. Also there is a huge increase in ‘smart phone’ use where many applications exchange so-called ‘keep-alive’ messages with the network, such messages periodically notifying an application, running on an equipment or server remote to the terminal and connected to the network, that the terminal is still connected to the network and wants to maintain an intermittent connection with the remote equipment or server. All this can lead to inefficient use of resources in the 3GPP system.
The 3GPP SA1 Working Group has already identified the above-mentioned transmission/reception of small amounts of data, identified as ‘small data transmission’, as one of the features of MTC. 3GPP specification TS22.368, s7.2.5, defines the MTC feature ‘Small Data Transmission’ which is intended, as suggested above, for use with MTC Devices that send or receive small amounts of data. Observed sizes of many instances of data exchange are of the order of 1 k octets (1,024 octets) but this should in no way be considered as defining or limiting the reference to small data within the context of the present invention. 3GPP is currently standardising the Machine Type Communication (MTC) and a specific feature of MTC is that there will be many instances of a very small data exchange (in one or both directions), and in the order of 1 IP packet for example. For this reason the 3GPP (SA1) has defined in TS22.368 a specific MTC feature called ‘Small Data Transmission’. Adoption of the present invention within, for example, 3GPP will allow for efficient small data transmission. Reference to small data therefore carries with it the implication such data may be treated differently from normal data. Thus, the above mentioned example in TS22.368 of 1 k octet is just one example and it should be understood that the understanding or definition of small data may be configurable (per subscription for example) by the network operators.
The 3GPP SA2 Working Group is currently investigating Small Data transmission optimisation (including keep-alive messages from smart phones) as part of the MTCe-SDDTE (Small Data and Device Triggering Enhancements) Work Item—see TR23.887, s5.1. A key issue of the investigation is ‘Efficient Small Data transmission’. The following functional requirement for Small Data transmission was agreed in TR23.887, s.5.1.1.2:                “The system shall support transmissions of small amounts of data efficiently with minimal network impact (e.g. signalling overhead, network resources, delay for reallocation).”        
SA2 has already agreed several possible solutions for efficient small data transmission in 3GPP technical report TR23.887. One of the possible solutions (Small Data Transfer starting from RRC IDLE, s5.1.1.3.1) includes transferring the small data as NAS signalling within RRC Connection Complete message (mentioned above) with use of pre-established NAS security and without establishing RRC security.                For this, in section 5.1.1.3.1 of the report, the following feature is suggested to be used: “For Small Data transmission UE's application requests NAS to request the UE's AS to establish an RRC connection “for a Tracking Area Update” and the RRC Connection is established with RRC establishment cause=‘mo signalling’ rather than cause=‘mo data’.”        
The use of a “mo-signalling” (mobile originated signalling) RRC cause allows the evolved Node B (eNB) to detect that a short-lived signalling procedure is in progress. The mo-signalling cause is employed to indicate that only signalling, and thus no data, is to be transmitted. The use of a “mo-data” cause serves to indicate to the network that data is also to be transmitted and if there is data for transmission as well, the network serves to configure the UE for measurement reporting. Small data would typically use a “mo-data” establishment cause and the network then configure the UE for measurements. Hence, it is unlikely that the Mobility Management Entity (MME) will download the security context to the eNB. Without the security context, handover cannot be performed. Thus, the eNB would not configure the UE to perform measurement reporting and radio resources would be saved. The above feature or adaptation allows the small data transmission to take place by modifying the behaviour of the eNB when a request for small data transmission is detected.
However another problem exists, as stated in the TR23.887:                “Editor's Note: Interactions of Low Access Priority with “mo-Signalling” are FFS (i.e., how can both be set as the Establishment Cause in the RRC Connection Request).”        
That is, for small data transmissions, it is here proposed that a “mo-signalling” establishment cause is used, rather than “mo-data” so that the network does not configure the UE for measurements and so thereby save network resources.